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Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document defines an XML format for the representation of civic
   location.  This format is designed for use with Presence Information
   Data Format Location Object (PIDF-LO) documents and replaces the
   civic location format in RFC 4119.  The format is based on the civic
   address definition in PIDF-LO, but adds several new elements based on
   the civic types defined for Dynamic Host Configuration Protocol
   (DHCP), and adds a hierarchy to address complex road identity
   schemes.  The format also includes support for the xml:lang language
   tag and restricts the types of elements where appropriate.
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1.  Introduction

   Since the publication of the original PIDF-LO civic specification, in
   [RFC4119], it has been found that the specification is lacking a
   number of additional parameters that can be used to more precisely
   specify a civic location.  These additional parameters have been
   largely captured in [RFC4776].

   This document revises the GEOPRIV civic form to include the
   additional civic parameters captured in [RFC4776].  The document also
   introduces a hierarchical structure for thoroughfare (road)
   identification, which is employed in some countries.  New elements
   are defined to allow for even more precision in specifying a civic
   location.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The term "thoroughfare" is used in this document to describe a road
   or part of a road or other access route along which a final point is
   identified.  This is consistent with the definition used in
   [UPU-S42].

3.  Changes from PIDF-LO

3.1.  Additional Civic Address Types

   [RFC4776] provides a full set of parameters that may be used to
   describe a civic location.  Specifically, [RFC4776] lists several
   civic address types (CAtypes) that require support in the formal
   PIDF-LO definition that are not in [RFC4119].

   These changes include new elements that are required to support more
   complex structures for naming street addresses.  This is described in
   more detail in Section 3.2.
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   +-----------+--------+-------------------------------+--------------+
   | New Field | CAtype | Description                   | Example      |
   +-----------+--------+-------------------------------+--------------+
   | BLD       |   25   | Building (structure)          | Hope Theatre |
   |           |        |                               |              |
   | UNIT      |   26   | Unit (apartment, suite)       | 12a          |
   |           |        |                               |              |
   | ROOM      |   28   | Room                          | 450F         |
   |           |        |                               |              |
   | PLC       |   29   | Place-type                    | office       |
   |           |        |                               |              |
   | PCN       |   30   | Postal community name         | Leonia       |
   |           |        |                               |              |
   | POBOX     |   31   | Post office box (P.O. box)    | U40          |
   |           |        |                               |              |
   | ADDCODE   |   32   | Additional Code               | 13203000003  |
   |           |        |                               |              |
   | SEAT      |   33   | Seat (desk, cubicle,          | WS 181       |
   |           |        | workstation)                  |              |
   |           |        |                               |              |
   | RD        |   34   | Primary road or street        | Broadway     |
   |           |        |                               |              |
   | RDSEC     |   35   | Road section                  | 14           |
   |           |        |                               |              |
   | RDBR      |   36   | Road branch                   | Lane 7       |
   |           |        |                               |              |
   | RDSUBBR   |   37   | Road sub-branch               | Alley 8      |
   |           |        |                               |              |
   | PRM       |   38   | Road pre-modifier             | Old          |
   |           |        |                               |              |
   | POM       |   39   | Road post-modifier            | Extended     |
   +-----------+--------+-------------------------------+--------------+

                     Table 1: New Civic PIDF-LO Types

   A complete description of these types is included in [RFC4776].

3.2.  New Thoroughfare Elements

   In some countries, a thoroughfare can be broken up into sections, and
   it is not uncommon for street numbers to be repeated between
   sections.  A road section identifier is required to ensure that an
   address is unique.  For example, "West Alice Parade" in the figure
   below has 5 sections, each numbered from 1; unless the section is
   specified, "7 West Alice Parade" could exist in 5 different places.
   The "RDSEC" element is used to specify the section.
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   Minor streets can share the same name, so that they can only be
   distinguished by the major thoroughfare with which they intersect.
   For example, both "West Alice Parade, Section 3" and "Bob Street"
   could both be intersected by a "Carol Lane".  The "RDBR" element is
   used to specify a road branch where the name of the branch does not
   uniquely identify the road.  Road branches MAY also be used where a
   major thoroughfare is split into sections.

   Similar to the way that a road branch is associated with a road, a
   road sub-branch is associated with a road branch.  The "RDSUBBR"
   element is used to identify road sub-branches.

   The "A6" element is retained for use in those countries that require
   this level of detail.  Where "A6" was previously used for street
   names in [RFC4119], it MUST NOT be used; the "RD" element MUST be
   used for thoroughfare data.

   The following figure shows a fictional arrangement of roads where
   these new thoroughfare elements are applicable.

         |                                                 ||
         |                                  ---------------||
         | Carol La.                           Carol La.   || Bob
         |                                                 || St.
         |              West Alice Pde.                    ||
    ==========/=================/===============/==========||===========
       Sec.1       Sec.2           Sec.3   |       Sec.4   ||   Sec.5
                                           |               ||
                                 ----------| Carol         ||
                                  Alley 2  |  La.          ||
                                           |               ||

3.2.1.  Street Numbering

   The introduction of new thoroughfare elements affects the
   interpretation of several aspects of more specific civic address
   data.  In particular, street numbering (the "HNO" element) applies to
   the most specific road element specified, that is, the first
   specified element from "RDSUBBR", "RDBR", "RDSEC", or "RD".

3.2.2.  Directionals and Other Qualifiers

   The "PRM", "POM", "PRD", "POD", and "STS" elements always apply to
   the value of the "RD" element only.  If road branches or sub-branches
   require street suffixes or qualifiers, they MUST be included in the
   "RDBR" or "RDSUBBR" element text.





Thomson & Winterbottom      Standards Track                     [Page 5]

RFC 5139                    Revised Civic LO               February 2008


3.3.  Country Element

   The "country" element differs from that defined in [RFC4119] in that
   it now restricts the value space of the element to two uppercase
   characters, which correspond to the alpha-2 codes in [ISO.3166-1].

3.4.  A1 Element

   The "A1" element is used for the top-level subdivision within a
   country.  In the absence of a country-specific guide on how to use
   the A-series of elements, the second part of the ISO 3166-2 code
   [ISO.3166-2] for a country subdivision SHOULD be used.  The ISO
   3166-2 code is formed of a country code and hyphen plus a code of
   one, two, or three characters or numerals.  For the "A1" element, the
   leading country code and hyphen are omitted and only the subdivision
   code is included.

   For example, the codes for Canada include CA-BC, CA-ON, CA-QC;
   Luxembourg has just three single-character codes, LU-D, LU-G, and
   LU-L; Australia uses both two- and three-character codes, AU-ACT,
   AU-NSW, AU-NT; and France uses numerical codes for mainland France
   and letters for territories, FR-75, FR-NC.  This results in the
   following fragments:

      <country>CA</country><A1>ON</A1>

      <country>LU</country><A1>L</A1>

      <country>AU</country><A1>ACT</A1>

      <country>FR</country><A1>75</A1>

3.5.  Languages and Scripts

   The XML schema defined for civic addresses allows for the addition of
   the "xml:lang" attribute to all elements except "country" and "PLC",
   which both contain language-neutral values.  The range of allowed
   values for "country" is defined in [ISO.3166-1]; the range of allowed
   values for "PLC" is described in the IANA registry defined by
   [RFC4589].

   The "script" field defined in [RFC4776] is omitted in favor of using
   the "xml:lang" attribute with a script subtag [RFC4646].

   It is RECOMMENDED that each "civicAddress" element use one language
   only, or a combination of languages that is consistent.  Where a
   civic location is represented in multiple languages, multiple
   "civicAddress" elements SHOULD be included in the PIDF-LO document.
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   For civic addresses that form a complex to describe the same
   location, these SHOULD be inserted into the same tuple.

3.5.1.  Converting from the DHCP Format

   The DHCP format for civic addresses [RFC4776] permits the inclusion
   of an element multiple times with different languages or scripts.
   However, this XML form only permits a single instance of each
   element.  Multiple "civicAddress" elements are required if any
   element is duplicated with different languages.  If the same language
   and script are used for all elements, or no elements are duplicated,
   the format can be converted into a single civic address.

   Where there are duplicated elements in different languages, a
   "civicAddress" element is created for each language that is present.
   All elements that are in that language are included.  Elements that
   are language independent, like the "country" and "PLC" elements, are
   added to all "civicAddress" elements.

3.5.2.  Combining Multiple Elements Based on Language Preferences

   If the receiver of the XML representation is known, and that receiver
   has indicated language preferences, a single XML format can be
   constructed using those preferences.  For example, language
   preferences can be indicated by the "Accept-Language" header in the
   SIP or HTTP protocols.

   All elements that have only one value, irrespective of language, are
   used.  Where multiple values exist, each value is assigned a
   weighting based on the language preferences.  The value with the
   highest weighting is selected.  An arbitrary value is selected if two
   values have the same preference, if there is no preference for the
   available languages, or if there are conflicting values with the same
   language.

3.6.  Whitespace

   The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 4
   uses a base type of "token" instead of "string" as used in [RFC4119].
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   The "token" type ensures that whitespace within instance documents is
   normalized and collapsed before being passed to a processor.  This
   ensures that the following fragments are considered equivalent by XML
   processors:

   <A4>North Wollongong</A4>

   <A1>North
     Wollongong</A1>

   <A1>
     North   Wollongong
     </A1>

   Whitespace may still be included in values by using character
   references, such as "&#x20;".

4.  Civic Address Schema

   <?xml version="1.0"?>
   <xs:schema
     targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
     xmlns:xml="http://www.w3.org/XML/1998/namespace"
     elementFormDefault="qualified" attributeFormDefault="unqualified">

     <xs:import namespace="http://www.w3.org/XML/1998/namespace"
                schemaLocation="http://www.w3.org/2001/xml.xsd"/>

     <xs:simpleType name="iso3166a2">
       <xs:restriction base="xs:token">
         <xs:pattern value="[A-Z]{2}"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:complexType name="caType">
       <xs:simpleContent>
         <xs:extension base="xs:token">
           <xs:attribute ref="xml:lang" use="optional"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>
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     <xs:element name="civicAddress" type="ca:civicAddress"/>
     <xs:complexType name="civicAddress">
       <xs:sequence>
         <xs:element name="country" type="ca:iso3166a2" minOccurs="0"/>
         <xs:element name="A1" type="ca:caType" minOccurs="0"/>
         <xs:element name="A2" type="ca:caType" minOccurs="0"/>
         <xs:element name="A3" type="ca:caType" minOccurs="0"/>
         <xs:element name="A4" type="ca:caType" minOccurs="0"/>
         <xs:element name="A5" type="ca:caType" minOccurs="0"/>
         <xs:element name="A6" type="ca:caType" minOccurs="0"/>
         <xs:element name="PRM" type="ca:caType" minOccurs="0"/>
         <xs:element name="PRD" type="ca:caType" minOccurs="0"/>
         <xs:element name="RD" type="ca:caType" minOccurs="0"/>
         <xs:element name="STS" type="ca:caType" minOccurs="0"/>
         <xs:element name="POD" type="ca:caType" minOccurs="0"/>
         <xs:element name="POM" type="ca:caType" minOccurs="0"/>
         <xs:element name="RDSEC" type="ca:caType" minOccurs="0"/>
         <xs:element name="RDBR" type="ca:caType" minOccurs="0"/>
         <xs:element name="RDSUBBR" type="ca:caType" minOccurs="0"/>
         <xs:element name="HNO" type="ca:caType" minOccurs="0"/>
         <xs:element name="HNS" type="ca:caType" minOccurs="0"/>
         <xs:element name="LMK" type="ca:caType" minOccurs="0"/>
         <xs:element name="LOC" type="ca:caType" minOccurs="0"/>
         <xs:element name="FLR" type="ca:caType" minOccurs="0"/>
         <xs:element name="NAM" type="ca:caType" minOccurs="0"/>
         <xs:element name="PC" type="ca:caType" minOccurs="0"/>
         <xs:element name="BLD" type="ca:caType" minOccurs="0"/>
         <xs:element name="UNIT" type="ca:caType" minOccurs="0"/>
         <xs:element name="ROOM" type="ca:caType" minOccurs="0"/>
         <xs:element name="SEAT" type="ca:caType" minOccurs="0"/>
         <xs:element name="PLC" type="xs:token" minOccurs="0"/>
         <xs:element name="PCN" type="ca:caType" minOccurs="0"/>
         <xs:element name="POBOX" type="ca:caType" minOccurs="0"/>
         <xs:element name="ADDCODE" type="ca:caType" minOccurs="0"/>
         <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
     </xs:complexType>
   </xs:schema>
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5.  Example

   <civicAddress xml:lang="en-AU"
     xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
     <country>AU</country>
     <A1>NSW</A1>
     <A3>     Wollongong
     </A3><A4>North Wollongong
     </A4>
     <RD>Flinders</RD><STS>Street</STS>
     <RDBR>Campbell Street</RDBR>
     <LMK>
       Gilligan's Island
     </LMK> <LOC>Corner</LOC>
     <NAM> Video Rental Store </NAM>
     <PC>2500</PC>
     <ROOM> Westerns and Classics </ROOM>
     <PLC>store</PLC>
     <POBOX>Private Box 15</POBOX>
   </civicAddress>

6.  Security Considerations

   The XML representation described in this document is designed for
   inclusion in a PIDF-LO document.  As such, it is subject to the same
   security considerations as are described in [RFC4119].
   Considerations relating to the inclusion of this representation in
   other XML documents are outside the scope of this document.

7.  IANA Considerations

7.1.  URN sub-namespace registration for
      'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr'

   This document defines a new XML namespace (as per the guidelines in
   [RFC3688]) that has been registered with IANA.

   URI:  urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr

   Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).
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   XML:

       BEGIN
         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
           <head>
             <title>GEOPRIV Civic Address</title>
           </head>
           <body>
             <h1>Format for Distributing Civic Address in GEOPRIV</h1>
             <h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr</h2>
             <p>See <a href="http://www.rfc-editor.org/rfc/rfc5139.txt">
                 RFC5139</a>.</p>
           </body>
         </html>
       END

7.2.  XML Schema Registration

   This section registers an XML schema as per the procedures in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr

   Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

      The XML for this schema can be found as the entirety of Section 4
      of this document.

7.3.  CAtype Registry Update

   This document updates the civic address type registry established by
   [RFC4776].  The "PIDF" column of the CAtypes table has been updated
   to include the types shown in the first column of Table 1.
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